1. Field of the Invention
The present invention relates generally to an improved data processing system and in particular to access entitlement. Specifically, the present invention provides a mechanism for logical management and provisioning of user access to business applications within the framework of an identity management system.
2. Description of the Related Art
An Identity Manager (IdM) is a management system which is used to provide centralized management of user identity and user accounts. One example of an identity management system is Tivoli Identity Manager (TIM), which is a product of International Business Machines Corporation. A user identity is a set of attributes which are used to uniquely identify the user. A user may perform certain actions or access certain information technology (IT) resources in a network based on the user's entitlements. Access entitlement is defined as the capability-based reasons that a user should be given a permission or set of permissions to access resources in an IT environment.
Access entitlement may also be applied to software applications. Applications written to run within a Java 2 Platform, Enterprise Edition (J2EE) environment are secured through two primary mechanisms. The JAVA2 security model provides a policy-based architecture of securing run-time control of code execution based on access permissions assigned to code sources. The J2EE model provides a role-based architecture of securing applications using pre-defined application roles for invoking each method of an Enterprise Java Bean (EJB) or by securing the Uniform Resource Identifier (URI) access of a servlet/Java Server Page (JSP). In both models, roles defined for these applications are driven by the application assembler's or application deployer's view of the enterprise.
Often, roles assigned to a user at the web service method level for one web application may conflict with roles assigned to the user for another application. In a large enterprise, managing users to assume certain roles for a large number of applications can become a tedious task for the system administrator. Thus, most J2EE Product and Tool Providers (e.g., WebSphere) attempt to simplify these tasks by assigning users to groups, and then managing a role-to-group mapping exercise for each application. However, this role-to-group mapping exercise creates another deployment task for the system administrator which can become complicated and hard to manage in a business setting. Thus, the system administrator must be able to delineate each role for each web application and determine how the roles of this application map to the business needs of the enterprise. The system administrator must then determine which user group or groups of the enterprise can assume that role.
A challenge for an administrator is to determine why each user belongs or should belong to a certain group, so that the users obtain the appropriate access to applications, but not to anything more. Group membership for users thus becomes a key element of enforcing security within an enterprise. In addition, each application may need specific information related to the user's profile. These applications may not want to share the identity information of one user from one application to another due to the privacy concerns. Thus, it becomes necessary for the system administrator to ensure that the appropriate set of personally identifying information is consumed by the appropriate set of applications.
Consequently, a system administrator may be required to provision the user profile in a corporate directory with only the requisite data that is absolutely essential for the user's needs. When users are disqualified from using a certain application, the user's profile must be appropriately adjusted to decommission the user from the appropriate set of user groups without affecting other applications. Often, this task is very confusing and conflicting, since application managers cannot keep track of a user's current status within the organization.
A Service Oriented Architecture (SOA) environment typically consists of a loosely-coupled set of applications hosted on multiple distributed platforms, where front-end components of an application portal often interact with back-end legacy applications. These legacy applications may span into different technologies, such as Customer Information Control System (CICS) and Information Management System (IMS). The distributed front-end infrastructure typically is web driven. Users from different communities access the application and invoke web services calls to the back-end legacy systems. The application may make several web services invocations to applications and data sources on diverse systems. The credentials of the authenticated identity validated in the front-end often needs to be propagated all the way to the back-end to establish the correct user credentials for the calls. However, a common problem in the SOA environment is choosing identities for the back-end legacy systems to which the back-end applications need to log on.
In one scenario, a generic pool of identities is used for the back-end legacy systems, and the front-end systems are mapped to these generic identities. However, by doing so, there is no individual user accountability maintained from end-to-end, which can be problematic with regard to auditing purposes. On the other hand, managing individual identities for every identity in the front-end implies managing identities for every identity at the back-end, which is a tedious task. As a result, managing identities, across diverse technology infrastructures, is often a major issue for SOA deployments. The legacy systems have a collection of data repositories like Resource Access Control Facility (RACF) and Access Control Facility (ACF2) which need identity/password management, or at least identities. Thus, each web service for SOA may result in a collection of identities sprinkled across the scope of the trust domain within which the transactions flow.